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loge INTRODUCTION 


A. THE "SOFTWARE CRISIS" 

In the late sixties it was realized that the importance 
of software was rapidly exceeding that of the hardware’ on 
which it was implemented. This was manifested by sharply 
escalating software costs while the cost of hardware under- 
went rather dramatic decreases. The reduced cost of compu- 
ters increased the demand for them and hence their numbers 
and the nmumber and variety of applications in which they 
were used also increased. There was a growing demand for the 
ability to convert existing applications software to make it 
executable on the newer, more powerful and less expensive 
hardware. The complexity and size of new applications also 
increased significantly with corresponding increases in the 
complexity and size of the software needed to support them. 
This in turn led to a far greater demand for software than 
the existing software industry could supply. Furthermore, 
it became apparent that software was not a “consumable” 
product that was used once or a few times and then dis- 
carded. It was becoming more and more like a large capital 
investment in a physical plant that required maintenance, 
alteration and enhancement throughout its relatively long 


useful life. 


Unfortunately, it was extremely difficult to make even 
trivial changes to the software of the day in a reliable, 
efficient, and effective manner. This was especially alarm- 
ing since the cost of developing software seemed to grow 
exponentially with 1ts size and complexity. This meant that 
even after making a substantial investment in software to 
support a complex application, the user faced an even 
Greater cost in maintaining its continued usefulness. In 
fact, it was found that most of the cost of a software 
system often occurred after it became operational leaving 
fewer and fewer resources available for new software devel- 
opment. It was from such observations and concerns that the 
term “software crisis" was born. 

Unhappily, things have not changed much and so a decade 
and a half later we still speak of being in the midst of a 
“software crisis" even though this immensely popular, but 
inaccurate, description may have done as much to obscure the 
real issues as it has to call attention to the legitimate 
concerns of the industry. 

Often the exact word used to describe an imprecisely 
understood situation is not of paramount importance. How— 
ever, “cerisis" usually describes a brief situation which 15 
largely beyond the control of those affected and in which 
immediate, short term actions may Significantly affect their 
chances for survival. The so-called "software crisis" 


Clearly has not been brief and is not beyond the control of 


those affected since they are also its creators. "We has 
met the enemy, and it 1s us.", from the comic strip Pogo by 
Walt Kelly accurately describes the current situation. Fur- 
ther, this "crisis" has not threatened the industry’s sur- 
Vival, and immediate, short term actions, while often help- 
ful, have not significantly reduced or altered the scope of 
the problem. Unfortunately, the perception of the software 
Gilemma as aocrisis has led to many proposals of limited 
scope, usually dealing with technical issues alone, that 
taken singly have had very little impact. If we are to have 
a more pronounced effect, we must broaden our outlook 


considerably. 


B. SOFTWARE ENGINEERING 

Shortly after the existence of the "software crisis" was 
recognized came the first hint that 1t wasn’t really a 
crisis but merely an undesirable situation in urgent need 
of amelioration. In the early seventies the term "software 
engineering" began to appear in the literature with increas-— 
ing frequency. This is significant because it implies a 
recognition of the need for a disciplined, orderly = and 
effective way to approach the problem of producing high 
quality software efficiently. Rather than merely responding 
to the more glaring aspects of a "crisis", we can and should 
develop engineering methodologies for the formulation = and 


analysis of problems having software solutions and for the 


specification, design, development, implementation, main-— 
tenance, and evolution of practical software systems that 
solve such problems. We also need, of course, to include in 
our methodologies a way of determining when a problem does 
not have a feasible software solution. 

Although the term “software engineering" iS now in 
rather common usage, finding a definition of the term is 
Surprisingly difficult, even in texts devoted to the = sub- 
ject. One particularly extreme example is (CRef. ij where 
the page given in the index as containing that author’s 
definition is completely blank! Nor is a definition to be 
found elsewhere in the text. However, some definitions can 
be found and we will state and analyze two of them here. 


In CRef. 23, Boehm presents the following definition: 


Software Engineering: The practical application of 
scientific knowledge in the design and construction of 
computer programs and the associated documentation re- 


Quired to develop, operate, and maintain them. 


and in CRef. 3] Jensen and Tonies offer Bauer’s definition 


taken from CRef. 4]: 


The establishment and use of sound engineering prin- 
Ciples (methods) in order to obtain economically soft- 


ware that is reliable and works on real machines. 
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The first definition has rather little to offer since 
the base Of well established "scientific knowledge” in soft-— 
ware design and construction 1s still quite small. However, 
this should not concern us too greatly. Humans were under- 
taking engineering projects of significant size and com- 
plexity, some of which have lasted more than ae thousand 
years, long before there was an established base of scien- 
tific knowledge applicable to them. In other words, engi- 
neers have never relied on scientific knowledge alone or 
waited for scientific advances before attacking pressing 
problems. Experience, ingenuity, and just plain trial-and- 
error have long been hallmarks of the engineering 
profession. 

The second definition may have more to offer. In the 
words of Jensen and Tonies (Ref. 3] 1t "...encompasses' the 
keywords that are the heart of all engineering discipline 
definitions: sound engineering principles, economical, 
reliable, and functional (works on real machines)." The 
critical question is whether we can reason by analogy from 
the sound engineering principles of other (non-software) 
engineering disciplines in general to a set (not necessarily 
complete) of sound engineering principles for software engi- 
neering in particular. Another somewhat less critical ques-— 
tion is whether principles that at first appear unique to 


software engineering can be effectively applied to other 


1! 


dirser plies. The former question will be of great concern 


throughout the remainder of this thesis. 


C. THE SOFTWARE ENGINEER 

We turn mow to the problem of defining, or at least 
identifying, the software engineer. In other engineering 
disciplines, we find "engineers" in many different roles. 
These range from that of a technician with limited formal 
education to that of a researcher with a doctorate degree. 
They also imclude many managerial functions. There are 


“chief engineers" who manage the engineering resources of a 


company, "project engineers" who are concerned with only a 
specific project or product line, "design engineers" who 
create and document designs, "production engineers” who de- 


termine how designs are to be implemented (manufactured), 
“quality assurance engineers" who devise and carry out tests 
on subassemblies and the finished product, "maintenance 
engineers" who perform preventive maintenance, repair and 
field alteration or upgrade functions, etc. In short, when 
we use the term "engineer" with respect to a particular 
product, we are speaking of anyone employed by the manufac-— 
turer who 1S responsible for any of the technical aspects of 
that product or directly manages those who are. Even the 
most cursory survey of the literature will show that all of 
the above functions have already been identified as being 


important to software engineering. 


Di. SOFTWARE ENGINEERING ENVIRONMENTS 

The problem with which we are faced can be stated as 
follows: "How can the productivity of competent software 
engineers at all levels be substantially improved?" Since 
competence is assumed, we must look at how these people are 
organized and used, and at the conditions under which they 
are required to work. In other words, we must examine the 
work environment. 

Environment tends to be a rather all-inclusive term. Et 
includes such obvious things as lighting, the architecture 
of the building, layout of office spaces, air quality, noise 
level, etc. It also includes the equipment and tools used 
for the production of products or as aids in carrying out 
other necessary functions (specification, design, main- 
tenance, Quality assurance, project management, etc.). 
Equipment and tools typically include all of the machinery 
and tools on the production floor, drafting equipment _(de- 
Sign and design documentation), test equipment and accurate 
measuring devices (quality assurance), and computers. 

In this thesis, we will focus on the equipment and tools 
portion of the total environment. We will define, for 
purposes of this discussion, a software engineering environ-— 
ment as the set of automated tools available for carrying 
out the various activities associated with (1) the formula-— 
tion and analysis of the target problem, (2) the speci- 


fication, design, development, implementation, quality 


cS 


assurance, maintenance, alteration, and enhancement of the 
software to solve that problem, and (3) the management ' of 
the personnel and other resources used in all these activi- 
ties. The purpose of this thesis is to present principles 
that should be used to guide the design of such 


environments. 


=e OUTLINE OF THE THESIS 
In the next two chapters we will build the basic 

Knowledge base needed in order to pursue a meaningful dis- 
cussion of software engineering environment design. Chapter 
II will provide a Brief historical perspective on how our 
present views of computers and software evolved. The objec- 
tive will be to identify as many prejudices and hidden 
assumptions as possible so we may relieve ourselves of their 
burden. The three main areas of discussion will be the 
programming language, operating systems, and hardware devel- 
opments of the past 490 years. 

Chapter III will present and discuss an outline of the 
general engineering methodology which seems to be common to 
all current fields of engineering. The objective here will 
be to provide a generalized model of the activities we call 
"engineering" with a view toward applying this model to 
software engineering in later chapters. 

Chapter IV will be concerned with software engineering 


issues. Given the background material on the general 
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engineering methodology and the historical perspective of 
the computer industry, we will analyze why "software engi -— 
neering" is not yet a mature engineering discipline. Ne 
will suggest how the maturation process might be accelerated 
through the software engineering environment concept. 

Chapter V will be concerned with some software manage- 
ment issues. Although we will not have time to examine 
these issues very deeply, we will emphasize their importance 
to the overall software engineering process and we will 
point out some types of automated aids which a software 
engineering environment could provide. 

In Chapter VI we will discuss ergonomic § issues. That 
is, we will look at the man-machine interface and emphasize 
1ts importance to the successful use of interactive tools. 
We will also argue that an integrated environment is needed, 
whereas amere "toolkit" of loosely related automated aids 
1s not sufficient. 

Finally, in Chapter VII we will draw some conclusions 
and address some philosophical issues. In addition, the 
principles which will be developed throughout the thesis 
will be gathered together in a compact form and placed in 


the appendix. 
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- HISTORICAL PERSPECTIVE 
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A. PROGRAMMING LANGUAGES 
1. Introduction 

Even though the general history of programming lan- 
Guage evolution is well known, we will review part of it 
here for the purpose of highlighting certain events”) and 
concepts that are key to our understanding of the present 
state of affairs regarding software engineering environ- 
ments. We will accomplish this by following a line of de- 
scent that leads more or less directly from the first major 
high-level language, FORTRAN, to one of the most recent —- 
Ada. In particular, we will wish to ponder the question of 
which software engineering problems are best addressed by 
programming language design and which are best addressed by 
other means. 

In CRef. SJ, MacLennan develops a number of prin- 
ciples which can be applied to the design of programming 
languages. However, these principles are, by and large, 
applicable to most engineering design problems and are not 
specific to language design. For this reason, they are 
listed in Appendix A for ease of reference. In spite of 
their general nature and the fact that he uses some very 
early programming techniques (pseudo-code interpreters) and 


languages (FORTRAN and Algol) to illustrate them, only one 
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of the principles he cites seems to have been consciously 
followed in those early days. Significantly, it is the 


first one mentioned in CRef. SJ] and is quoted below: 


The Autorwation Principle 


Automate mechanical, tedious, or error-prone activities. 


The key to programmer productivity seemed to lie in 
providing higher levels of abstraction for programming pur- 
poses which could then be reduced to machine level = instruc- 
tions by automatic means. Given the lack of previous expe- 
rience and the hardware limitations of the period, the 
higher level languages developed prior to 1979 turned out 
remarkably well. However, there were some unspoken, perhaps 
even unconscious, assumptions about software that became 
increasingly false with the passage of time. These included 


such assumptions as 


Programs apply to specific, well-defined problems. 
Programs are at most a few thousand lines long. 
Programs have a relatively short life expectancy. 


Programs are rarely modified. 
While the incorrectness of some of these became apparent to 
writers of “systems software” (e.g. operating systems and 


compilers) as early as 1966, their incorrectness with 
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respect to “applications software" (1.e@. programs written by 
users for their own purposes) was not appreciated until 
much, much later. Because high-level languages were thought 
of as applying more to applications software than to systems 
software, this lack of foresight was the main contributor to 
the shortcomings of high-level languages and the paucity of 
other software development tools for many years. 
2. FORTRAN 

The first major high-level language was FORTRAN. [t 
was developed by John Backus of IBM between 1954 and 1958. 
FORTRAN is an acronym for FORmula TRANslation and this is 
precisely what the language was designed to do. It was 
aimed at the numerical problems of the scientific community. 
It was heavily machine dependent, as the correspondence 
between its control structures and the branching instruc- 
tions of the IBM 799 computer shows. From a linguistic 
point of view, it was "grown" more than designed. In fact, 
Backus 1s quoted in (Ref. SJ] as saying (in 1978), “As far as 
we were aware, we simply made up the language aS we went 
along. We did not regard language design as a difficult 
problem, merely as a simple prelude to the real problem: 
designing a compiler which could produce efficient pro- 
Grams." Although FORTRAN was to come under heavy fire on 
linguistic grounds in later years, it was enormously = suc— 
cessful. It proved the viability of high-level languages 


when many doubted their feasibility and it was a huge 
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commercial success. Much of 1ts initial machine-dependence 
was removed in later versions and it became available on the 
computers of almost every manufacturer. 

3. Algol 

After FORTRAN proved that programs written in high- 
level languages could be automatically translated to ef- 
ficient and logically equivalent machine language programs, 
a number of computer scientists on both sides of the Atlan- 
tic decided that a new “universal", machine’ independent 
language suitable for communicating algorithms between = hu- 
mans as well as between humans and machines was needed. The 
end result was a language called Algol. The work on Algol 
produced a great many significant advances in programming 
language design, probably more than any other single piece 
of work to date. Nevertheless, its goals were essentially 
the same as those of FORTRAN and it too suffered from the 
tacit assumptions stated above. 

Algol suffered from another problem as well. In 
their enthusiasm for increased expressive power. the design- 
ers of Algol included some very general control structure 
constructors. These made it possible to represent some very 
sophisticated algorithms very compactly, but at the same 
time made those representations almost unreadable and in 
some cases misleading to all but the most experienced. 
Despite this generality, Algol remained a relatively compact 


language until its 1968 (Algol-68) incarnation. 
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en TEE 

Algol wasn’t the only language to suffer from the 
drive to generalize. While FORTRAN and Algol were aimed at 
scientific computing, another language named COBOL (COmmon 
Business Oriented Language) was developed. Having never 
jumped on the Algol bandwagon, IBM wanted to develop a 
“universal” language of its own aimed at both the scientific 
and business communities. It therefore began an effort in 
1964 to extend FORTRAN with ideas from COBOL and Algol. It 
soon became evident that instead of an extended FORTRAN, a 
completely new language would result. This language was 
called PL/I (Programming Language One). It was an extremely 
large and complex language, the mastery of which was next to 
impossible. It had so many features which could interact in 
sO many different ways that it wasn’t even possible for = an 
individual programmer to learn only a subset of features for 
his own use while ignoring the remainder. The drive to 
incorporate 1n one language all the features that any pro- 
grammer could possibly want or use very nearly resulted ina 
language that no programmer could understand. 


- 


S- Pascal 
Other significant events in software development 
were taking place. In 196& Bohm and Jacopini published 
CRef. 61 proving that any flowchart can be converted to one 


containing only certain types of flowchart elements - the 


so-called “structured programming" forms. The significance 
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of this work was that it showed complex and undisciplined 
control structures to be unnecessary. In the years) that 
followed, many computer scientists argued that use of com- 
plex control structures was also unwise. A new concern for 
such things as software readability and reliability was 
Growing as some of the earlier assumptions about the nature 
of software began to crumble under the weight of experience. 
Unfortunately, those assumptions listed earlier still re- 
mained largely intact as shown by the following excerpt 
taken from Dijkstra’s now famous 1968 letter [Ref. 7] to the 
editor of the Cowwpunications of the ACH: "My first remark 
is that, although the programmer’s activity ends when he has 
constructed a correct program, ..." 

In 1976 the language Pascal was) introduced. Its 
control structure constructors were simple and direct imple- 
mentations of those associated with the mew concept of 
"structured programming". Pascal was also a strongly typed 
language and had a block structure similar to that of Algol. 
This new language represented a quantum change in the nature 
Of programming languages in its attempt to encourage = and/or 
enforce certain programming practices. The emphasis on pro- 
gGramming style was consistent with its goal: to be a suit-— 
able language for teaching programming. Because of its 
small size, excellent (though certainly not perfect) design, 
rich and efficient set of data structure constructors, and 


its strong typing it has not only met its original goals it 
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has been successfully extended and used in many "real world" 
applications. Like Algol before it, Pascal has influenced 
the design of almost all later languages, including one of 


the latest - Ada. 


Finally during the seventies the early assumptions 
about programs having a short life, being rarely modified, 
being relatively small, and being applied to specific, well- 
defined problems were revealed and discarded - violently. 
Everywhere one turned in the computing world, the phrase 
“software crisis" seemed to be emblazoned in neon lights. 
The situation wasn’t far short of a general panic. Everyone 
seemed to have an idea of what the "key" problem was’ and 
thought that solving that one problem would cure most, 1f 
not all, of the software industry’s ills. Of course, for 
each such perceived problem there was at least one proposed 
solution. The only central point of agreement was that 
something had to be done. 

Into these stormy seas was launched the Department 
of Defense project to develop a new standard language to 
meet the needs of software development for “embedded” compu-— 
ter applications, i.e. situations where a computer is con- 
tained in and an integral part of a larger system (e.g. 
weapons systems and command, control and communications 
systems). DOD’s experience with such software had been an 


expensive one up to this time. A wide variety of languages 
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were employed and some of them were used nowhere else in the 
world. This made software maintenance and the integration 
of subsystems from different vendors extremely difficult. 
The outcome of the work to overcome these and other dif- 
ficulties was the programming language Ada. 

like PL/I, Ada has drawn on several earlier lan- 
Quages and like PL/I it is avery large and complex lan- 
guage. However, the reasons for its large size and com- 
plexity are quite different from those of PL/I. The two 
main driving forces behind Ada’s size are its generalization 
and improvement of Pascal features and its attempt to in- 
corporate a number of software engineering/management func— 
tions. For example, software design reusability 1s ad- 
dressed by generic packages which contain templates’ for 
generating Ada code. like many other languages, Ada sup- 
ports separate compilation of modules but unlike them it 
also provides a considerable amount of error checking across 
modules. It remains to be seen if these and the many other 
features introduced by this new language have been = chosen 
and implemented with sufficient care to avoid repeating the 
PL/I experience. 

Another aspect of Ada which is of particular in- 
terest here is the inclusion of an Ada program support 
environment (APSE) in DOD’s overall software development 
strategy for embedded systems. The rationale for this is 


described in CRef. 83. Unfortunately, the implementation of 
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a standard APSE is still far in the future even though at 
least one Ada compiler has already been implemented = and 
certified. Nevertheless, the ongoing DOD effort stands as 
the most comprehensive approach to a software engineering 
environment to date. 
7. Summary 

The first high-level language had only one goal: 
the automatic translation of mathematical notation to effi- 
cient machine language programs. Later, more expressive 
power and generality were incorporated with little thought 
Given to the consequences or implications of such a move. 
These traits and the changing nature of the software being 
developed caused many to question the wisdom of large com- 
plex languages. Many programming practices were questioned 
and a number of techniques such as structured programming, 
modular programming, etc. were devised. Out of this work 
came languages that in addition to performing the transla- 
tion function also encouraged these newer techniques. While 
this initially resulted ina smaller, simpler language, the 
latest offering has tried to address so many programming 
issues that its great size and complexity has led many to 
doubt its viability. To quote C. A. R. Hoare (Ref. 9] on 
Ada, "We relive the history of the design of the motor car. 
Gadgets and glitter prevail over fundamental concerns of 


safety and economy." 
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B. OPERATING SYSTEMS 

In the very earliest days of electronic computers, those 
who designed and built them also operated and = programmed 
them. The early machines were dedicated to single users. 
Before a program could be run, there was a certain amount of 
“setup" work to be done to get the machine ready. It wasn’t 
long before the operators/programmers wrote software to 
automate some of the setup activity. This marks the begin- 
nings of what we now call operating systems. 

As long as computers were dedicated to single users, 
operating systems were only used to provide services to the 
human operator. Later, as computers grew into complex com- 
puting systems capable of processing many programs concur- 
rently and utilizing a large number and variety of periph- 
eral devices, software was developed to manage system re- 
sources. The objectives of this management'=§ included (1) 
security to control the interaction between applications 
programs and the hardware and to keep applications programs 
from interfering with each other, and (2) wnaxinun throughput 
to ensure that the system’s resources were utilized as 
efficiently as possible. 

By this time computers were being widely used commer-— 
cially and customers demanded, im addition to an operating 
system to manage hardware resources, that a growing number 
and variety of service or utility programs be supplied = as 


well. Vendors supplied file management subsystems, high 
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level language compilers, accounting software for resource 
usage, etc. Since all of these were tightly coupled with 
the "bare" operating system and were supplied along with it 
in one package, the entire package came to be called "the 
operating system." As the hardware continued tO grow in 
Capability while decreasing in cost, interactive use re- 
placed the previous batch mode of operation. This led to 
even more demands on the operating system and its associated 
utilities. Interactive communications with large numbers of 
terminals, onm-line utilities for file creation and manipula-— 
tion, and text editors were but a few of the many additional 
demands placed on “operating systems." 

What all this means is that, in effect, software devel- 
opers have come to view the operating system as the "soft- 
ware engineering environment." Unfortunately, so many de- 
mands are placed on an operating system that its developers 
can give only limited attention to software engineering 
utilities. So far, these are usually limited to assemblers, 
compilers, subroutine libraries, a limited object code 
librarian facility, linkers, loaders, general purpose text 
editors and file manipulation utilities, assembly level 
debuggers, and, with luck, source level debuggers that are 
consistent with the compilers. As we will see in Chapter 
IV, these tools address only a small fraction of the funda- 


mental needs of a "Software engineering environment." 


C. HARDWARE 

We will not recount the history of computer hardware 
here since it is so well documented elsewhere. However, it 
is important to examine the changing nature of human-machine 
interaction that has resulted from hardware advances. 

We thave already noted how the difficulty of machine 
language programming led to the invention of high-level 
languages and how the desire to automate operator functions 
led to the development of operating systems. Another impor- 
tant characteristic of the earlier computers was that they 
operated almost exclusively in betch mode. Programs were 
recorded on punched cards and submitted in their entirety 
for translation to machine code. Programs were altered by 
removing, replacing and moving punched cards within the 
"source deck." Since nothing could be done to automate this 
manual process, software programming aids were necessarily 
limited to the features of the programming language itself, 
the diagnostic abilities of the compiler, and the diagnostic 
abilities of the operating system (register status reports 
On program abortion, "core dumps", etc). 

When the hardware became capable and cheap enough to 
support interactive users and vast amounts of online stor- 
age, the possibilities for new applications, including soft-— 
ware engineering environments, exploded. Furthermore, the 
continued decrease in computing costs means the possibili- 


ties are continuing to expand at a dizzying pace. We can 
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now put the computing power, speed and data storage capa- 
bility of what was a multimillion dollar mainframe computer 
a few years ago on the desk of every individual in an or- 
ganization, if we so desire. Likewise, the cost of graphics 
display devices have fallen into the realm of affordability. 
If one picture really is worth a thousand words, there are 
few places where pictorial representations would be more 
welcome than in software development. Whether we can effec-— 
tively apply such vast amounts of computing power to appli- 
cations in general will depend in large part on how much of 
that power we can apply to software engineering environments 
in particular. 

Another hardware topic currently under vigorous’) debate 
involves instruction sets. We have seen how hardware avail- 
ability influenced the growth and nature of high-level pro- 
gramming languages. This was not a one-way street, however. 
After a time, hardware designers began to consider how high- 
level languages would be implemented on the hardware they 
were designing. Soon they began to include instructions 
specifically for certain high-level constucts. For example, 
special index registers and instructions were included for 
iterative loops and array indexing. The hardware stack, 
immensely useful for languages that permitted recursion, was 
another feature frequently added (see p. 39 of CRef. 19]). 
Even more elaborate and "high-level" instructions have been 


included on some machines. 


This trend has been called into question by supporters 
of a concept popularly called "RISC" - Reduced Instruction 
Set Computers CRef. 113. RISC adherents claim that a small 
instruction set made up of very simple and very fast opera- 
tions 1s better than avery large one more (apparently) 
attuned to high-level languages. They claim increased ef- 
ficiency based on research which indicates that a reasonably 
"intelligent" compiler could do more optimization and there- 
fore generate more efficient object code than it could if 
forced to use the "higher-level" and more complex  instruc-— 
tions. They also claim more reliability based on the old 
notion that simple machines are inherently more reliable 
than complex ones. There may be a lesson here for designers 
of software engineering environments. Which is better, a 
Simple language supported extensively by the environment’ or 
a large, complex language that presumably requires less 


support”? 


D. CONCLUSIONS 

The vast majority of research and development effort ex- 
pended in the computer field since its beginnings in the 
1949s has been directed toward three major areas: progr am— 
ming languages, operating systems, and hardware. The criti- 
cal importance of software was recognized in the early 
seventies along with a rather long list of problems) encoun- 


tered in the design, development, and maintenance of 
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reliable, effective software. The primary vehicle for ad- 
dressing these problems was language design. Pascal and Ada 
are two related examples of languages designed during this 
period. However, the persistence of the "software crisis" 
indicates that language design alone, while important, will 
not solve the pressing problems of the software industry. 
Advances in hardware and operating systems have made a great 
deal of computing power available to software developers but 
they have not yet harnessed more than a tiny fraction for 


their own purposes. 
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III. ENGINEERING METHODOLOGY 


A. INTRODUCTION 

The “engineering” of a product can be thought of as four 
basic types of activity. These are design, implementation, 
maintenance/evolution and the management of all these activ- 
ities. We will discuss each of these briefly in the 
sections that follow. 

Before we begin to look at the general nature of en- 
Gineering as a human activity, we should dispense with one 
particular misconception that seems to haunt the software 
industry. In CRef. 123, Peters notes that, "Many software 
developers who .lack an engineering background think of en- 
gineering as an: exact discipline that produces’ formulated, 
precise, ec caerorm solutions to problems. The inexacti- 
tude associated with software design seems intolerable to 
many designers, who feel that if there were a true engineer- 
ing discipline for software, all estimating and scheduling 
problems would go away." He continues, "Actually, nothing 
could be further from the truth: Engineering depends as 
much on common practice and empirical knowledge as it does 
On scientific fact." Certainly this observation is) borne 
out by the number of times "rules of thumb," "safety fac 


tors," and the like are used in all engineering disciplines. 


As we look at the general engineering method for clues 
regarding the way we should ccnduct software engineering 
endeavors, we must not lose sight of sur objective. We wish 
to improve the ability of software engineers to produce high 
Quality software efficiently. Any such improvement that 


promises significantly more in benefits than it consumes in 


resources 1s worth exploring. 


B. DESIGN 


According to Jensen and Tonies CRef. 31, the engi- 
neering design process can be broken into six phases. These 
are illustrated in Figure i. Note its neat. straight line 
structure. While it provides a good way organize the dis- 
cussion which follows, it 1s not very representative of the 
way an engineering project actuaily proceeds. Recognizing 
this, Jensen and Tonies provide a second diagram in (CRef. 3] 
which 1s reproduced here as Figure 2. With its mumerous 
feedback loops, it 1S a much more accurate rendition af 
actual engineering processes. 

One other feature of these diagrams requires com- 
ment. The "Implementation" phase is included because of the 
importance of its feedback to all the other phases. In the 
discussion which follows, implementation will not be con- 
sidered part of the design process but, for reasons which 


will become clear, as a sS@parate entity. 


ud 
" 


recognition of problem 
to be solved 

























solutions to similar irrelevant information 
problems vy and misleading data 
PROBLEM 
FORMULATION 
general formulation of problem 
PROBLEM 
ANALYSIS 
detailed problem definition 
(specs, limits, criteria, etc.) 
SEARCH 
potential solutions 
and partial solutions 
DECISION 
chosen solution (rough form) 
SPECIFICATION 
reports 
and documentation design model 


IMPLEMENTATION 


documentation : 
working solution 


Fig. 1 Engineering Design Process 


NEW PROBLEM 


FORMULATION 


ye Val 
K 


DECISION 





Fig. 2 Realistic Engineering Design Process 


34 


2. Problem Formulation 
According to (Ref. 33, the inputs to the problem 


formulation process are the recognition of the problem to be 


solved, solutions to similar problems, and a fair amount of 


irrelevant and misleading information. The output is a 
general, but accurate, statement of the problem to be 
solved. The primary goal of the engineer in this phase is 


to gain a broad perspective on the problem and to remove 
prejudices caused by "misleading opinions, current solu- 
tions, and standard ways of viewing the problem." (CRef. 3] 
This usually involves a great deal of human-to-human = com- 
munication as all parties try to bridge what William James 
characterized as, "The most immutable barrier in nature...", 
the one, “... between one man’s thoughts and another’s." 

Another ob jective of the engineer at this time is to 
avoid thinking of possible solutions. A method frequently 
used 1s the so-called "black box" technique. Here, the 
problem is viewed as that of finding a process to transform 
inputs to outputs (e.g. steel into car bodies). In this 
phase, the objective is to identify the inputs and outputs 
but to keep the details of the transformation process hidden 
in the “black box" that forms the bridge between them. 

S$. Problem Analysis 
In this phase, the engineer sets out to sharpen his 


understanding of the problem and to formulate a list of the 


constraints and requirements that will be placed upon any 
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solution. These constraints and requirements may be imposed 
by management (e.g. company standards), the customer (e.g. 
price and delivery date), or nature itself (e.g. strengths 
of materials). Another objective is to develop criteria for 
selecting the best of several possible solutions later in 
the project. Engineers, being pragmatists, normally will 
see several ways of solving any problem and so there must be 
some criteria for choosing among them. 

One of the most useful ways of sharpening one’s 
understanding of a large and complex problem is to decompose 
it into successively simpler problems. This technique is 
known as stepwise or successive refinenent. Although there 
is no fixed algorithm for this process, engineers’ usually 
try to do functional decomposition. That is, they try break 
the overall function a device must perform into a set of 
smaller and simpler functions which have a composition 
equivalent to the original total function. Since more than 
one decomposition is possible, there may be several attrac-— 
tive alternatives. 

During problem analysis it all but impossible to 
keep from thinking of potential solutions. It 1s natural 
for solutions or partial solutions to suggest themselves 
during the analysis. The disciplined engineer will note 
these and lay them aside for consideration during the search 
and decision phases. The undisciplined engineer may well 


allow his analysis to become biased by a potential solution. 


4. search 
In this phase the objective is to locate and de- 
scribe aS many potential solutions as time and other re- 
sources permit. The Broader the field of selection the more 
ideas the engineer will have to draw upon in selecting the 
approach he will finally use. It 15 important at this point 
that no attempt be made to eliminate potential solutions or 
partial solutions no matter how awkward they might seem = on 
the surface. Selection is the objective of the next phase 
while collection is the objective of this phase. 
Up to this point we have been using the term "solu- 
tion" without having defined it in any special way. While a 
special definition is probably not necessary, it 1S impor- 
tant to realize its use in the current context implies an 
approach or route to be followed in obtaining a complete and 
detailed solution and not the complete solution itself. 
J. Decision 
This phase is where the various proposals are objec— 
tively compared to find a "best" approach to use for com- 
pleting the solution design in sufficient detail to enable 
implementation. In order to carry out such an objective 
comparison, CRef. 3] proposes the following four steps: 
1. The selection criteria must be defined, and the 


relative weight of the individual elements of the 
criteria assigned: 
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- The performance of the alternate solutions) with 
respect to these criteria must be predicted as 
accurately as possible: 

The performance of the alternate solutions must be 
compared on the basis of their Predicted 
performance: 

4. The selection of the preferred solution must be 
made. 
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The selection criteria may be based on a number 
diverse aspects of problem solution such as deadlines’ for 
product delivery, availability of the technology required to 
implement the solution, manufacturing costs, product ' per- 
formance, reliability, maintainability and ease of use, etc. 
The assignment of weights is necessarily a difficult and 
subjective task but the most difficult part of this process 
is the performance prediction of step two. Such predictions 
can only be based on rough estimates and the judgement of 
the engineer since the solutions themselves are still rather 
vague and i111l-defined. Furthermore, it is almost certain 
that none of the proposed approaches will provide the "“opti- 
mal" solution {even 1 one could be recognized as such) 
because the search phase did not exhaust the solution space 
but merely sampled from it. For this reason, 1t 1S a very 
poor engineer who can study the design of a very good engi- 
neer without finding some way to improve upon it. 

6. Specification 

This is the phase we most often associate with 

engineering design. It is here that the rough solution 1s 


refined and developed in considerable detail, and the bulk 


of the design documentation produced. The design documenta- 
tion is an absolutely necessary and integral part of any 
engineering methodology. Its most obvious purpose is to act 
as the output of the design process and provide all the 
information necessary for actual implementation of the de- 
Sign. However, design documentation sees considerable ser- 
vice prior to completion of the design process. It is used 
for design reviews which ensure the continued feasibility of 
the solution and provide others involved in the project’ an 
opportunity to suggest improvements while also keeping them 
up to date on project progress. Design documentation also 
provides an opportunity for error detection. Drawing check-— 
ers can detect and report such things as internal dimen- 
sional inconsistencies, incomplete bills of materials, etc. 
They can also check to make Sure that mating parts, if 
within the specified tolerances, will in fact mate in all 
cases. Although this is a tedious, mundane task, it 1S very 
important to detect and correct such errors before the 
implementation phase begins. Correction of even minor de- 
Sign errors during implementation can be extremely expensive 
whereas their detection and correction prior to that time is 
relatively inexpensive. 

Once the design has been specified, documented, and 
verified avery important event occurs. Up to now only the 
design staff under the supervision of the project engineer 


has been directly involved. Upon completion, the design is 
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"released" for implementation (production). All of the 
design documentation is then passed from the “engineering" 
(design) staff to the "production" staff. Although this 


does not end the design engineer’s involvement in the pro- 


ject, it does reduce it rather sharply. With respect to 
this project, he becomes a consultant to the “production" 
department. He clarifies the design documentation if 


needed, makes design changes to accomodate unforseen manu- 
facturing difficulties, etc., but is otherwise uninvolved 
with the actual implementation of his design. 

This separation of design activities from implemen- 
tation activities is one of the most important principles of 
modern engineering. In the "functional decomposition" of 


the engineering process that has occurred naturally over the 


years, design and implementation have become separate 
modules. The interface between them is the design documen-— 
tation, which is made up largely of drawings —- the well- 


known engineering blueprints. 


ee IMPLEMENTATION 

The last of the phases in the Jensen and Tonies CRef. 3] 
description of the engineering design process is that of 
implementation. It should be clear from the preceeding 
discussion why it is considered as a separate entity from 
design in this thesis. It is in this phase that an actual 


artifact 1s produced according to the specifications of the 
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designer. For purposes of this discussion, we will postu- 
late a "production staff" whose responsibility is to develop 
manufacturing and quality assurance methods, and to carry 
them out to produce and assemble parts into a complete 
working product. Often this staff is broken into three 
"departments" -—- methods, production, and quality assurance. 
When a design is released for production, someone must 
decide how to manufacture and assemble the component parts 
in order to arrive at a finished product. Normally, the 
manufacture of a part requires many operations (e.g. machin-— 
ing operations) to be performed in a specific sequence on a 
piece of raw material before completion. This task is often 
Given to a “methods department" which must develop these 
sequences of operations along with intermediate and final 
inspections for quality assurance. Once these have been 
specified, they are sent to the production and quality 
assurance departments along with a work request specifying 
how many parts of each type are to be made and blueprints of 
the design engineer’s original drawings. In this way, the 
methods department quite literally "programs" the production 
floor (e.g. machinists and inspectors) with respect to the 
manufacture and inspection of each part. (Keeping the total 
production floor operating efficiently for maximum through- 
put (productivity) and minimum idle time is the job of the 
production department.) This "programming" function becomes 


even more obvious when numerically controlled (NC) machines 
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are used. Methods departments also "program" the assembly 
floor in a Similar fashion by providing instructions for 
assembling the parts and testing the assemblies to ensure 
they work properly. They may also be charged with develaop- 
ing procedures for implementing field modifications to be 
carried out by the maintenance department. 

Once the manufacturing and inspection procedures have 
been determined, production proceeds. We will not attempt 
to analyze this part of the process since it varies consid- 
erably depending on what type of product is being produced. 
For this discussion it is sufficient to assume simply that 
as components are produced they are inspected for "correct-— 
ness" at several levels (e.g. parts, subassemblies, complete 
machine) using the inspection criteria contained in the 
design documentation. Rejected components are either dis- 


carded or reworked until they can pass inspection. 


D. MAINTENANCE /EVOLUT ION 

All man-made devices require some sort of maintenance. 
Routine maintenance activities (e.g. periodic lubrication, 
preventive maintenance) are specified in the design documen- 
tation. Such things as “wear tolerances" are also specified 


sO maintenance personnel can detect when parts need replac- 


ing. When a device begins to malfunction, repairs must be 
made. In such cases the maintenance person must do some 
"trouble-shooting" to locate the cause of the malfunction. 
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His primary aids in this endeavor are past experience = and 
the original design documentation. 

In addition to making repairs and performing preventive 
maintenance, maintenance personnel typically must report 
the results of their activities. Reviews of maintenance 
reports and customer complaints and comments often reveal 
design deficiencies or identify needed enhancements. Once 
identified, management must decide whether to pursue them. 
If changes are to be made, the design process described 
above is initiated and the engineering process continues 
from that point with one additional input - the original 
design documentation. That is, the design engineers go 
"back to the drawing board" with copies of the current 
design and make the necessary changes via the full design 
process from problem formulation to the release of the 


modified design for production. 


E. MANAGEMENT 

If left to his own devices, a good design engineer might 
never complete a design. This 1s because engineers’ are 
rarely satisfied with their own designs and can always see 
some way to make them better. However, economic realities 
restrict time and other resources to finite levels. Manage- 
ment must determine these levels and then husband the 


available resources to produce a profitable outcome. 


In (Ref. 153. Reifer of TJ7RW Systems states that 
management has "five constituent parts:" 
(1) Planning 


(2) Controlling 
(3) Staffing 


(4) Organizing 

co) Directing 
He goes on to state eighteen “fundamental principles of 
management" which are reproduced in Appendix B. We will 
mention a few of these in the next chapter. For now, we 


will consider only the five management functions stated 
above. 
According to CRef. 13], “Planning is the primary 
function of management ...", and 
Plans are either strategic or tactical. Strategic 
plans identify major organizational objectives and govern 
the acquisition, use, and disposition of resources to 
achieve those objectives. Tactical plans deploy resources 
to achieve strategic objectives. Plans help managers 
decide in advance what will be done, how it will be done, 
and who will do it. 
Plans provide a standard against which progress can be 
measured and communicate management’s goals and expectations 
to the organization. 
Organizational structures are created By managers’ so 
that people can work together effectively and efficiently to 
achieve the desired goal. Once created, the organizational 


Structure must be staffed with personnel having the requi- 


Site skills and attitudes. When the staffing is completed, 
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the manager must direct and lead the staff to the desired 
goal. 

Finally, there is the matter of control. No manager can 
be effective if he cannot control his project. Maintaining 
adequate control is just as essential as good planning. As 


a 


(Ref. 13] puts it, 


Planning and control are inseparable activities. Une 
Planned actions cannot be controlled because control  in- 
volves keeping events on course by correcting deviations 
to plans. Plans furnish the standards for control. Con- 
trols should be diagnostic, therapeutic, accurate, timely, 
understandable, and economical. They should call atten- 
tion to significant deviations and should suggest alterna- 
tive means of correcting the difficulty. 

One of the traditional ways to exercise control in 
engineering is to require management approvals at several 
points in the product’s life cycle. During the design 
process, design documents are carefully reviewed, the costs 
and benefits of various design alternatives are carefully 
estimated and compared, compromises are made and finally a 
course of action 1S approved. This happens many times and 
at many levels before the final design is released. some 
decision are "internal" to the company while others) require 
significant customer involvement. Similar things happen 
during the implementation and maintenance/evolution phases. 


The importance of the control function cannot be over- 


emphasized. 
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ee DESIGN DOCUMENTATION 
1. Introduction 

We have seen that design documentation is used in 
all aspects of engineering. Because of its crucial impor-— 
tance to engineering methodologies, it deserves closer exam- 
ination. We will now try to determine those features which 
contribute to its central role in the engineering process. 

2. Levels of Abstraction 

Engineering design documentation provides descrip- 
tions of the product at many levels of abstraction. There 
is a hierarchy of descriptions that vary in detail from the 
general outline of the finished product down to the most 
intimate details of the smallest component part. In mechan-— 
ical engineering, for example, there are "detail drawings” 
Of each unique part and various levels of "assembly draw- 
ings" for the assemblies and subassemblies that make up the 
final machine. As the assemblies become larger, their rep- 
resentations must necessarily show only major features while 
suppressing many details. However , sometimes a particular 
feature is shown in great detail by superimposing a “magni- 
fied view” on an otherwise high-level representation. This 
demonstrates the property of "fine granularity” present in 
engineering design documentation. Fine granularity may be 
defined as the ability to simultaneously display different 


levels of abstraction so that both the details of a feature 


and the context in which that feature occurs may be shown. 
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This ability to represent a complex device at vari- 
ous levels of abstraction is the key to engineer’s ability 
to design complex devices that actually work. If the engi- 
neer could not decompose a complex design problem into a set 
of smaller and simpler design problems with corresponding 
smaller and simpler implementations, modern technology sim- 
ply would not be possible. 

3S. Types of Abstraction 

There is often more than one conceptual view of a 
product and its components. In electronics engineering, a 
logic circuit can be viewed as a set of connected transis-— 
tors, capacitors, resistors, etc. It can also be viewed in 
terms of logic gates (AND, OR, NAND, XOR, etc.) which are 
represented by entirely different symbols from those used to 
depict the electrical components. Even in mechanical engi- 
neering we have “exploded views" of assemblies to illustrate 
how the assembled parts relate to one another even = though 
the parts will never actually appear in the “exploded” 
configuration. 

4. Completeness 

Taken as a whole, the design documentation provides 
a consplete Pica fication from which the artifact may be 
implemented. It specifies both the "perfect" artifact and 


the types and degrees of imperfections that can be toler- 


ated. Design documentation does not, however, specify how 
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the implementation 1S to be accomplished. Different imple- 
mentors are free to employ different methods tO accomplish 
the same end. 
3S. Universality 

Design documents tend to be universally understood 
by engineers in the same field (mechanical, electrical, 
etc.) regardless of any differences among them including 
national origin. That 15S, a mechanical engineer in the 
United States can largely understand the design documen- 
tation generated by a mechanical engineer in Japan even 
though neither engineer has met the other or even under- 
stands the other’s native tongue. This is because engineer-— 
ing design documentation depends heavily on graphical repre- 
sentations and the use of standard symbols and formats 
accepted worldwide, which together form a more-or-less “uni- 
versal design language". 

6. High Cost 

The generation of design documentation iS an ex- 
tremely expensive process. Often years of design effort are 
expended before the first component of the end product is 
produced. The necessity of this large “design overhead" has 
long been recognized and accepted by the engineering profes-— 
sion. This 1s because the investment 1S repaid many times 
Over in reduced communications costs throughout the pro- 
duct’s life. Without design documentation, the designer 


would have to either perform all the engineering functions 
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(design, implementation, maintenance, etc.) himself or 
personally educate all those responsible for non-design 
activities. 
7. A Valuable Asset 

The three. immediately preceeding characteristics 
make the design documentation of its products one of the 
most valuable and closely guarded assets of a company. 
Because of their completeness and universality, design docu- 
ments could be used by competitors to produce the same or 
Similar products. The expense of their development makes 
them attractive targets of industrial espionage since even 


their reproduction from an actual artifact 1S an extremely 


expensive proposition. 


G. CONCLUSION 

We have looked at the general engineering methodology 
used to design, implement, maintain and improve a product. 
In so doing, we found that a central and crucial role is 
played by the design documentation produced by the design 
engineers. In fact, the design documentation is essential 
to all "engineering" aspects of the product life cycle 
including the design process itself, the production of the 
product, the maintenance of the product, the enhancement or 
evolution of the product over time and the management of all 


these activities. 
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IV. SOFTWARE ENGINEERING ISSUES 
A. INTRODUCTION 

Before we can call ourselves "software engineers" we 
must subscribe to some software engineering methodology. We 
have already described the general engineering methodology 
in use today. However, this description lacks the detail 
necessary for actual practice. 

In the last fifteen years, a number of software develop- 
ment techniques have come into being but a complete engi- 
neering methodology does not yet seem to exist. There are a 
number of companies whose sole business is software genera- 
tion for various customers and many others which develop 
Significant amounts of software "in-house" for their own 
purposes. We could analyze the software-related activities 
of these companies to determine their “software engineering 
methodologies." In so doing, we would probably find that 
most really have no well defined methodology. In other 
words, if we were tasked with developing a software engi- 
neering environment for any of these firms, we would face 
all the same problems and difficulties we face when design- 
ing software systems for other “unsophisticated” users. We 
would have to listen to the customer’s stated needs’ and 


desires and then figure out how he really operates and what 


he really needs and wants. We might even have to change his 
way of doing business to enable him to meet his goals. In 
short, we must know what we are trying to support before we 


can support it. This leads to the following principle: 


Methodology Support Principle 
A software engineering environment should be designed to 


support a specific engineering methodology. 


The central position of the engineering methodology in 
the "ecology of software development environments” and its 
eight essential characteristics are given in  CRef. 14]. 
These eight characteristics basically include features 
already identified here (in rough form at least) but they 
are included as Appendix C for easy reference. 

An interactive software engineering environment must 
address three basic classes of issues - (1) technical, (2) 
managerial and (3) ergonomic. These are not strictly or- 


thogonal because real environments have two fundamental 


properties. First, "Everything is connected to everything 
else" and, second, "There is no such thing as a “*free 
lunch." Taken together, these characteristics imply that 


altering one feature of an environment will have sore effect 
on the remainder of the environment. However, for discus-— 
Sion purposes, we will treat technical, managerial and ergo- 
nomic issues separately although we will see a good deal of 


overlapping among them. 
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B. TECHNICAL ISSUES 
1. Software Design Support 

When the word "engineering" is mentioned two things 
immediately come to mind —- technology and blueprints. Engi- 
neers are people who design devices and structures which can 
be implemented using current or forseeable technology, and 
who document these designs with engineering drawings (blue- 
prints) and related materials. The importance of design 
documentation to the engineering process and the essential 
properties of this documentation were described in the pre- 
vious chapter. 

Let us now consider the term "software engineering". 
Certainly we should associate “software engineering" with 
"technology" since it is part of the computer industry which 
is one of the most technologically advanced and rapidly 
evolving industries on the planet. But where are the blue- 
prints? What does a "software blueprint" look like? Just 
how does one “design” a software system or even a part of 
one? Given a "design", how can it be communicated to an 
implementor? If there is a “key" to the software crisis, it 
most likely will be found in the answers to these questions. 

While there is no software design documentation 
system that enjoys all the advantages possessed by those of 
the other, more mature, engineering disciplines, there area 
a number of documentation techniques that have been pro- 


posed. One of the oldest of these is flowcharting, which 


can be traced back to pre-FORTRAN days according to (Ref. 
hod. Although it was widely used for atime, flowcharting 
fell into disfavor for a number of reasons. It was regarded 
as cumbersome because the time and effort required to con- 
struct flowcharts was significant. Brooks CRef. 16] charac-— 
terized flowcharting as a, "eee Space-hogging exercise in 
Grafting." Furthermore, since the software implementations 
Of the designs represented by flowcharts were more easily 
altered than the flowcharts themselves, programmers tended 
to modify the software without making corresponding changes 
in the flowcharts. As Yourdon (CRef. 17] observed, eeens 
flowcharts are rarely maintained with any enthusiasm after 
the program has been finished.” Hence, the implementation 
soon deviated from the design and so the design documents 
were discarded. (Yes, this zs engineering heresy!) 

There were other problems as well. Flowcharts rep- 
resent only the flow of control through a program. This is 
like having blueprints with only one view. Ledgard and 
Chmura CRef. 18] argue, "..e- Program flowcharts can easily 
suppress much useful information in favor of highlighting 
sequential control flow." Hence, many important features 
cannot be seen clearly and some cannot be seen at all. 

Another problem lay in the designs themselves. Be- 
fore the advent of "structured programming", the control 
Structures in most programs could only be described as 


"helter-skelter" - that is, no particular structure at all. 


Confused "designs" resulted in equally confused flowcharts 
and program code. 

Perhaps the greatest problem was one which remains 
to this day. There 1s no more significant indicaticn of 
software engineering’s immaturity than the lack of separa- 
tion between design and implementation activities. In the 
preface to CRef. 19], Chu states, "The application of engi- 
neering methods and practices to software development '=§ im- 
plies (1) the separation of software design from software 
implementation and (2) a software-blueprint interface be- 
tween software design and software implementation." As long 
as design and implementation remain inseparable, engineer- 
ing in the modern sense cannot take place. This was the 
most important reason flowcharts were largely abandoned. 
Because the designer was also the implementor (programmer in 
both cases), the making of flowcharts or other design docu- 
mentation served no useful purpose in his view. As Yourdon 
CRef. 17] also observed, "Indeed, most programmers’ will 
admit that they rarely bother writing the flowchart until 
the program has been finished (Cand then only because the 
manager insisted on it)..." In other words, software is 
often developed without any design documentation at all. 

Other design documentation aids have been proposed 
in the years since flowcharting was introduced. These in- 
Clude Nassi-Shneiderman Charts (Ref. 263, HIPPO (Hierarchy 


plus Input-Process-Output) CRef. 213, PDL (Program Design 


Language) [CRef. 22], Structure Charts (Ref. 231, and the 
"software blueprints” of (CRef. 19] as well as some others. 
This last technique at least strives toward providing all 
the essential characteristics of engineering design documen- 
tation although it still lacks the richness and variety of 
the more mature documentation systems. Chu’s “software 
blueprint” provides three levels of abstraction, four 
processing data (as distinguished from control data) types, 
seven processing data structures, two control data types, 
two control data structures, a large number of high-level 
data operators, seven reference structures (e.g. procedure 
reference structure, data reference structure), and some 
other constructs (e.g. defined data types) as well. This 
techni que does not make extensive use of graphical 
representations, although Chu allows that such representa- 
tions could be usefully employed in conjunction with the 
“software blueprint." 

All ae the above aids seem to have been used with at 
least some success. Unfortunately, we do not have space 
here to explore them in detail. For our present discussion, 
the details are not that important. The important thing for 
designers of software engineering environments to realize 1s 
that some reasonably complete design documentation system 
must be chosen before a software engineering environment 
that supports software design may be developed. We state 


the following principle: 


Design Documentation Principle 
A software engineering environment should support a design 
documentation system that is (1) complete, (2) capable of 
representing appropriate levels and types of abstractions 


with fine granularity, (3) universal, and (4) economical. 


Completeness and universality serve the same func- 
tion in software engineering as in other engineering disci- 
plines. They allow design to be largely divorced from other 
engineering activities while reducing the total communica- 
tions burden over the product’s life. Although universality 
may seem an impossible goal at this early stage of software 
engineering’s development, we can begin by following the 
example set by the other engineering disciplines. That iS, 
we need to develop graphical symbols and standard formats 
for representing the various important features of a soft- 
ware design. Flowcharts and hierarchy charts already can be 
considered universal and adaptations to increase their util- 
ity would be very valuable for this reason. Easily under- 
stood graphical representations of certain common data 
Structures such as stacks, queues, and linked lists could be 
developed without much difficulty. In short, the key to 
universality lies in the consistent use of graphical repre- 
sentations, formats (both graphical and textual), and sym- 
bols that are easily recognized even though only limited 


standards for these currently exist. 
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Abstractions also serve the same funct1ion as in 
other disciplines but we will list a few examples here to 
show how they apply to software engineering. Programs can 
be viewed in many ways and so several types of abstraction 
are useful. The most obvious and familiar view is the 
textual (program listing) one which is often "pretty print- 
ed" to emphasize certain structures. (As design documents, 
listings can at best be regarded as analogous to the "de- 
tail" drawings of the mechanical engineer. It 1S probably 
best think of listings as representing an implementation 
rather than a design.) Flowcharts depict control flow, 
hierarchy charts’ show the procedure reference structure, 
data flow diagrams illustrate how and when data items are 
modified, etc. The reader can no doubt think of several 
other types of useful abstractions. 

By having a design documentation system for represent— 
ing the various aspects of a software design, we can analyze 
the design to see if it satisfies various design criteria. 
For example, if we can display all of the connections be- 
tween modules, we can estimate levels of coupling. We can, 
like the drawing checkers mentioned in the previous chapter, 
inspect the design for technical flaws, inconsistencies, and 
adherence to design and documentation standards mandated by 


management. This suggests the following principle: 
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Enforcewment/Aid Principle 
A software engineering environment should enforce tech- 
nical correctness and conformance with management policies 


while aiding the user in maintaining these standards. 


It should be made clear that "technical correctness" 
in this context does not necessarily mean "proof of correct- 
ness" in the formal sense. Although engineers of all disci- 
plines use mathematical calculations in creating and check- 
ing their designs, rarely if ever is the "correctness" of a 
design confirmed by a formal mathematical proof. We are 
more concerned here with such mundane things as ensuring 
that the interface specifications between modules are con- 
sistent or that the design does not call for the use of side 
effects. Of course, where proofs of correctness can be 
accomplished economically, they should be done. 

There is an important corollary to the Enforcement/ 
Aird ee rinciple. Designs change frequently while they are 
being developed as well as less frequently after release. 
Steps must be taken to ensure that changes to one part of a 
design are accompanied by appropriate changes to the remain- 
der of the design in order to maintain consistency. It Ss 
altogether too easy to make a seemingly innocuous design 
change that actually proves to have widespread ramifica- 


tions. This leads to the 
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BONSISCENCY TE rINnGE2 ple 
"Permanent" alteration of one view of a design should not 
be "accepted" by the environment until all related views 


are made to be consistent with the change. 


Related views include all levels and types of abstraction 
that show either the altered module or modules that inter- 
face with it. "Permanent" and “accepted” are quoted to call 
attention to the need for allowing temporary inconsistencies 
so local evaluation of alternative design changes and envi- 
ronmental transition states may be accomodated. 
2. Implementation Support 

It is difficult to say where design ends and imple- 
mentation begins in software development. Here, we will 
define zpwplewentation as that activity which transforms a 
software design into an executable program or system of 
programs. We will take executable to mean either directly 
executable on the target hardware (machine code) or trans-— 
latable by automatic means to a form that is directly exe- 
cutable. Thus, progrerpring languages are considered dis- 
tinct from design languages. This distinction is far from 
being absolute, however. For example, Pascal could be used 
as part of a design language system for specifying assembly 
language programs to be created by hand if a compiler’ for 
the target machine either did not exist or generated intol- 


erably inefficient machine code. Another thing making the 
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design/implementation boundary fuzzy is that no matter how 
complete the design, programmers are always allowed some 
leeway and so perform some detailed design functions. 
Therefore, placement of the design/implementation boundary 
will be a difficult chore for the developers of software 
engineering methodologies for the forseeable future. 

a. Enforcement/Aid and Consistency 

implementors face many of the same sorts of 
problems as designers but ina different context. For 
example, the Enforcement/Aid and Consistency principles can 
be applied to such things as ensuring consistency between 
the implementation and the design, enforcing various pro- 
gGramming standards and policies, enforcing syntactic and 
semantic rules of the programming language being used _ for 
the implementation while aiding the programmer in conforming 
to those rules, etc. 

When applied to programming itself. the Enforce- 
ment/Aid principle can be extremely powerful. It 1S, in 
fact. the driving principle behind most modern interactive 
"programming environments" including the Cornell Program 
Synthesizer CRef. 24], the DWIM (Do What I Mean) feature of 
Interlisp CRef. 253, and any syntax-directed editor. These 
tools show that there is nothing sacred about having the 
compiler perform enforcement functions. In fact, given 
today*S computing power and the prevalence of interactive 


use, one could effectively argue that compilers should pot 
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be in the enforcement business at all But should handle only 
the translation function from a form that can be made human- 
readable to a form suitable for machine execution. Note the 
possibility here of storing a program in an intermediate 
“bidirectional” form that could be “unparsed”" into a textual 
or other understandable form (one direction), or directly 
translated into executable machine code (other direction) by 
either an interpreter or a compiler. 

The Enforcement/Aid principle can be used to de- 
fine a completely new programming language or effectively 
alter an existing one. For example, in (Ref. 26], Kernighan 
and Plauger describe RATFOR, a preprocessor for FORTRAN that 
adds Pascal-like control structure constructors) and charac-—- 
ter manipulation to FORTRAN by translating these constructs 
from RATFOR to FORTRAN which can then be translated into 
machine code by the FORTRAN compiler. A syntax-directed 
editor for RATFOR that restricted the use of the GO TO 
statement (which RATFOR does not) could aid in the en- 
forcement of structured programming techniques on FORTRAN 
programmers, particularly if it was interactive (which 
RATFOR is) not) and provided templates (like the Cornell 
Program Synthesizer) and other aids for program = construc— 
tion. It is easy to see how strong typing could, in es- 
sence, be added to FORTRAN as well. 

The Enforcement/Aid principle can also be used 


to effectively create a subset of a language. In fact, the 
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Cornell Program Synthesizer does precisely this for PL/I. 
Of particular interest in this regard will be the relation- 
ship between Ada and various implementations of the APSE. 
While DOD has decreed that it will allow no subsets of Ada, 
it is difficult to see how this can be effectively pre- 
vented. Ada*s large size and complexity practically beg for 
some sort of subsetting. As Hoare observes in CRef. 9], 

It is not too late! I. believe that by careful pruning 
of the ADA language, it 1s still possible to select a very 
powerful subset that would be reliable and efficient in 
implementation and safe and economic in use. The sponsors 
of the language have declared unequivocally, NoOwever, that 
there shall be no subsets. This is the strangest paradox 
of the whole strange project. If you want a language with 
no subsets, you must make it swall. 

The APSE provides the mechanism for putting subsets into 
effect from a programming standpoint even if no "incomplete" 
versions of the Ada compiler are allowed. 
b. Structure Manipulation 

Those who perform any amount of word processing 
are familiar with the concepts of deleting and inserting 
words, sentences, and paragraphs. Word processors are 
Organized around these structures because they are such an 
intimate part of written prose in most western languages. 
It seems clear, then, that software engineering environments 
should provide programmers with the capability to manipulate 


structures common to software development. An example of 


this is the Cornell Program Synthesizer which provides’ for 
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direct manipulation of structural elements in the PL/I 
subset it. defines. "While" loops, "“Tf-Then_Else" blocks, 
expressions, etc... Can be inserted or deleted as complete 
entities. Furthermore, the cursor movements are keyed to 
such structural elements rather than the textual elements of 


lines and characters. This illustrates the 


Structure Manipulation Principle 
The user of a software engineering environment should be 
able to create, reference, locate, alter and delete 
structures defined within the environment. He should also 
be able to display meaningful representations of them 
within the context of any applicable type or level of 


abstraction. 


Note that although our examples apply to actual "source 
code" generation, this principle applies to other activities 
as well. For example, the programmer might wish to inter- 
rupt his programming and view some part of the design docu- 
mentation or consult the subroutine "librarian" to see if a 
needed function has already been implemented. 
Cc. Analysis Support 

During the construction of a program or module, 
the programmer will need to perform various analyses to 
check his work, locate bugs, and ensure conformance with 
standards and policies of his immediate supervisor. There 


are two types of analysis —- static and dynamic. 


exes 


In static analysis, the programmer checks’ the 
static structure of the program for various attributes. For 
example, he might check a FORTRAN subroutine to ensure that 
certain formal parameters did not appear on the left of = an 
assignment operator if the design called for them to be used 
for input only (like in parameters in Ada) or check an 
entire program to ensure that no coercions are present. In 
Pascal, he might want to ensure that a certain global vari- 
able was referenced only in certain procedures. These exam- 


ples lead us to the 


Static Analysis Principle 
A software engineering environment should (1) allow the 
user to make assertions about the static structure of a 
module, program, or system of programs and then report 
back to the user which assertions are not valid and why, 
and (2) allow the user to request certain information 
about the static structure and then report this informa- 


tion back to the user in a lucid format. 


For example, if a user asserted that the actual parameters 
used in calling a particular procedure never contained named 
or literal constants, the environment should be able to 
check for conformance with this assertion and, if exceptions 
were found, provide the user with a list of where the 


offending procedure references were located. It should also 
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be able to display these in any applicable context, na gin 
lighting in some way the offending parameters themselves. 

The Static Analysis principle is very Similar to 
the Enforcement/Aid principle in many respects. The main 
difference is that the Enforcement/Aid principle is more 
concerned with general rules which all software generated by 
an organization must obey. The Static Analysis principle 
addresses features and characteristics peculiar to the spe- 
cific program under development which is why the programmer 
himself needs the ability to make assertions and have them 
checked. Quality assurance persons can also use static 
analysis to provide defense in depth (see principle 3 In 
Appendix A). 


The purpose of dynamic analysis is to study 


program behavior. In order to be complete, a set of design 


documentation must contain acceptance criteria. Some of 
these may be static, others dynamic. When we speak of 
"testing" and “correctness" regarding software, we are 
usually thinking of the program’s behavior. We may need to 


know if a certain set of inputs produces the expected out-— 
puts, if procedures are called in the expected sequence, the 
frequency distribution of procedure calls for atypical 
input stream, actual execution times, or similar facts con- 
cerning the program’*s behavior. To support this need, we 


state the following principle: 
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DynaBic Analysis Principle 
A software engineering environment should (1) allow the 
user to make assertions about the dynamic structure of a 
module, program, or system of programs and then report 
back to the user which assertions are not valid and why, 
and CZ) allow the user to request certain informaticn 
about the dynamic structure and then report this informa- 


tion back to the user ina lucid format. 


These last three principles strongly suggest that a 
software engineering environment should provide many of the 
Same types of support we normally associate with database 
and/or artificial intelligence applications. Certainly 
database and artificial intelligence techniques should be 
considered in the design of any software engineering 


environment. 


C. CONCLUSIONS 

We have seen that before we can design an environment to 
support a software engineering methodology, we must first 
define that methodology. We have also seen that design 
documentation 1s just as essential to software engineering 
as 1t 18 to the other engineering disciplines although no 
system of design documentation presently exists that has all 
the fundamental characteristics of those associated with the 
aore mature disciplines. The idea that software developers 


seem to have been so busy building systems to increase the 
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productivity of others that they haven’t yet performed that 
service for themselves has been observed. Finally, we saw 
indications that during design and implementation a signifi- 
cant "knowledge base” 1s Built up and that the techniques of 
database management and artificial intelligence might be 


brought to bear ina productive manner. 
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Ve. MANAGERIAL ISSUES 


If the design and implementation of reliable, effective 
software are not well understood, then the management of 
projects which have such responsibilities must be a total 
mystery. In CRef. 3], Tonies observes, 

If management science 1S immature, then we can expect 
software management science to be especially immature, 
Since the software industry is itself so new and is 
expanding so quickly. The probability, then, of finding 
effective software management would seem to be small. ier 
1S. 

We cannot hope to treat this immensely important topic 
adequately here. However. we will point out some issues 
which could be addressed by a software engineering environ- 
nent. In particular we will look briefly at the planning 
and control functions of management. 

In Ref. 27], Thayer, Pyster and Wood report the results 
of a survey of "... experienced and knowledgeable data 
Processing managers as well as some of the leading computer 
scientists from industry, government, and universities with- 
in the US and abroad." In this survey, "..-eparticipants 
were asked to express their opinions concerning 24 hypothe- 
Sized major issues or problems of SEPM." SEPM is an ab- 


oreviation for Software Engineering Project Management. The 


28 hypothesized problems are reproduced in Appendix  0O. 
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Eight of the ten hypothetical planning issues, three of the 
six control issues, Organizational accountability, and the 
staffing of the project manager position were all considered 
definite problems. None of the 29 issues could be elimi- 


nated as a unimportant. 


A. PLANNING 

Planning requires estimation and estimation presupposes 
the existence of some system of measurement. So far, 
researchers have had a very difficult time in their attempts 
to develop meaningful measurements of software. In (CRef. 
283, $a number of papers on software metrics have been col- 
lected. In their preface, Perlis, Sayward and Shaw note 
that. “No matter what aspect of software one studies, there 
1s a noticeable lack of collected and categoried field data 
on which to build." They continue, “... past software 
projects have rarely integrated data collection into their 
production schedule ..." When this is combined with 
DeMarco’s assertion in CRef. 29] that software managers are 
such poor estimators because they don’t collect data on 
project performance and compare it with the actual results 
in even the most trivial manner so they can learn from their 
mistakes, we see that the need for data collection is a 
universal one. Ironically, there are few situations where 
large-scale data collection would be easier than ina soft- 


ware development project, where most of the work is done on 
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one or a few computers. Even 1f we don"t have a well estab- 
lished set of metrics, almost any data collected would be 
useful to the collecting organization in making future esti- 
mates as well as being more grist for the research mill. We 
don*t have space here to discuss exactly what kinds of 


project data might be collected but we can state the fol- 


lowing principle: 


Data Collection Principle 
A software engineering environment should provide for the 


unobtrusive collection of software management data. 


In addition to the collection of general management 
data, one specific class of data should be collected “(for 
each software product developed. Enough data should be 
collected to establish a complete set of audit trails. Pe 
should be possible to follow, after the fact, a software 
development project from beginning to end through its 
residual dccumentation. For example, an "auditor" should be 
able to find the alternative designs considered and the 
rationale used for choosing the one that was actually used. 
He should be able to find out who made a major design deci- 
sion, who implemented a particular module, who tested and 
accepted it, the test specifications and actual test re- 
sults. the costs of these activities, and other such useful 
inf Om@mari on. Such things are not only useful for general 


Dlanning purposes, they are also valuable to those who may 
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be tasked with designing enhancements or alterations to a 
particular system and they are essential to any system of 


configuration management. We state the following principle: 


BUudg2eEmirtail Pr2inezpl & 
A software engineering environment should maintain audit 
trails showing the relationships between specifications, 
designs, implementations, maintenance and enhancements, 
and the resources expended in these activities. Further, 
such audit trails should be navigable in both directions 


from any point. 


Another service which the environment should provide is 
that of librarian. Software engineering efforts are 
notorious for "reinventing the wheel," that is, failing to 
effectively use the knowledge gained from or output of 
previous efforts. If the results of earlier work were 
organized and cataloged, managers could find at least some 
data to guide their estimates. Technical personnel could 
likewise locate and study designs or implementations which 
might be applicable to the problem at hand. It is often 
more efficient to use or combine existing products or 
designs than to create a totally new product. We therefore 


state the following: 


Infora@ation Organization Principle 
The information gleaned from the various documentation and 
data collection efforts should be organized for easy 


reference and maintenance. 
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Chapter 1 of CRef. 293 begins with the statement, \ 2a 
can’t control what you can"t peasure." We submit that it is 
even more difficult to control what you can’t even see. 
Many software managers must feel like the fabled emperor who 
wanted some new clothes. When they ask for software project 
progress reports, the one thing they rarely see is the 
software or its design. The control issue is the main 
reason why design documentation 1S 50 important to 
management. 

We saw earlier how the Enforcement/Aid principle applied 
to designers and implementors. Recall that this principle 
involved ensuring "conformance with management policies.” 
In order to carry out this function, the following principle 


should be applied: 


Management Control Principle 
A software engineering environment must be controliable by 


the management of the organization it serves. 


Tee 


C. ORGANIZATION 

Organizational structures are developed so that a varie- 
ty of persons with expertise in a variety of needed disci- 
plines or specialties can work together effectively and 
efficiently to achieve a common goal. The computer support 
for an organizational structure should reflect that struc- 


ture. This leads to the 


Urgapeenagnonal Structure Principle 
A software engineering environment should be partitionable 
along the structural lines of the organization so that 
individuals and groups may have the necessary levels of 
Privacy and isolation from other individuals and groups, 
and so the communications among them may be reasonably 
controlled by forcing them through established interfaces. 
However, it should also be possible to allow information 
to flow across organizational boundaries, when needed, 


through specially designated and controlled interfaces. 


This is really an application of the Information Hiding and 
Manifest Interface principles (numbers 4 and 7 respectively 
in Appendix A) and the Management Control principle (above) 


to human organizational structures. 


pee GONCLUSIONS 
In this brief chapter we have tried to emphasize the 


importance of management to software engineering, but 


without delving into the various details and styles of 
management. The principles we Rave outlined are very broad 
and deal only with automated support of management § func- 
tions. No doubt anv practicing software manager could think 
of a host of additional features and tools he would like to 
see in a software engineering environment. The one concept 
that should be clear at this point is that designers of 
software engineering environments should not be satisfied 
with supporting only the technical personnel. The solving 
of management problems is just as important to the goal of 
increased software productivity as the solution of technical 
problems. However, software management problems are much 
more difficult to solve and are often not regarded as being 


within the realm of "computer science." 
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VI. ERGONOMIC ISSUES 

A. INTRODUCTION 

So far we have looked at some of the engineering and 
managerial issues involved in software engineering environ- 
ment design. We will now look at some ergonomic § issues. 
That 15, we want to examine the interface between the human 
user and the automated environment in which he will (we 
hope) immerse himself. 


Many of the principles stated up to this point have 


ergonomic overtones and some, like the Structure 
Manipulation principle, could even stand as ergonomic 
Principles alone. We wish to continue with a list of 


Principles which apply to the design of any interactive 
application. Before going on, however, we wish to take time 
to emphasize the need for good ergonomic features. 

The first and foremost reason for good ergonomics is 


that tools which are difficult or awkward to use will be 


ignored. A similar fate awaits tools which are unpredict- 
able or unresponsive. To employ a greatly overworked 
phrase, the tools must be "user friendly." The second 
reason is that the investment required to bring an 
"unfriendly" tool on-line 1s probably not much less’ than 
that required for a similar "friendly" tool. We shouldn’t 


waste money on tools that will be discarded. A third reason 
is Producti vicy. Even if designers and programmers) must 
work with the given tools because no others are available, 
they will be much more productive with "friendly" tools. 

We have been speaking here of "tools" as if we were 
going to supply them ina "toolkit." We actually wish to 
avoid such a concept. Obviously a software engineering 
environment must put tools (capabilities) into the hands of 
its users. However, it will not do to have a toolkit of 


miscellaneous devices, however useful, that do not work 


together in harmony. This makes the environment as a whole 
"unfriendly." Nevertheless, this is how most of the present 
environments have come about. (Smalltalk is a notable ex- 


ception.) To quote Spier et al. CRef. 38], "Generally, 
tools sprang into spontaneous existence as desperate pro- 
grammers resorted to improvisations such improvisations are 


colloquially termed ‘midnight projects’.' This is certainly 
how the tools of UNIX originated although it 1s claimed by 
Kernighan and Mashey (CRef. 313 that the system was Built up 
by evolutionary means (survival of the fittest tools) which 
achieved a reasonable degree of integration. Nevertheless, 
they also note in CRef. SiJjJ that things could be better in 
this regard. 

In CRef. SE], Hansen lists a number of principles for 


the design of interactive systems. We will examine these 


briefly in the sections that follow and add a few as well. 
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B. USER ENGINEERING PRINCIPLES 
The user will need to communicate with the environment 


Via some "language of interaction. It 1s clear that such a 
language Should be designed in accordance with the 
principles of language design formulated in (Ref. SJ] and 
reproduced here as Appendix A. This leads to our first 
principle: 
Interface Language Design Principle 
The language of interaction between aieuser and an 


interactive application should be designed according to 


the principles of good programming language design. 


The first principle listed in CRef. S32] is "Know the 
User". This principle is seen as having two parts. First, 
Hansen suggests building, "se. a profile of the intended 
user: his education, experience, interest, how much time he 
has, his manual dexterity, the special requirements of his 
problem, his reaction to the behavior of the system, his 
patience." Second, and more important, is the need for the 
designer to appreciate two traits common among humans: Caen 
they forget and they make mistakes." 

While the second assertion is well beyond dispute, the 
need for a detailed user profile is highly questionable. In 


the first place, humans are highly variable beings and in 


the second place, most of the characteristics listed above 


rare 


will change over time. Therefore, rather than having the 
designer tailor the system to a particular type of user, he 
should, at most, discriminate only among broad classes of 
users, e.g. professionals vs. amateurs. In any case, he 
should make the system flexible enough to allow users to 
“customize” the interface to their own liking. The old 
engineering adage, "Tf you can*t make it right, make it 
adjustable" applies. 

In the sections that follow, we will follow Hansen’s 
Outline and comment on his principles. 

1. “Minimize Memorization" 

The first principle listed in this category is that 
of "Selection Not Entry." Here, Hansen recommends selecting 
items from menus via keyboard codes. While this certainly 
has advantages for novice users, menus can quickly become 
frustrating for experts. The word processor on which this 
document was produced provided multiple levels of inter- 
action. First: it allowed selection of a "help level" to 
determine how much command information was displayed con- 
tinuously. Second, for multi-stroke commands, rapid typing 
of the keystrokes resulted in immediate execution of the 
commands while a delay following the first keystroke caused 
a menu of second-stroke commands to be displayed. In other 
words, it minimized the level of required penorization while 
allowing the user to take advantage of the increasing level 


of expertise he gained naturally through experience. In 
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feet. 309), Spier et al. recommend, “at least two modes of 
interfaces *novice”’ mode and ‘expert’ modet preferably 


more." This leads to the 


Neezoweevel Help Principle 
For any interactive tool, there should be a hierarchy of 
"Help" levels ranging from no prompts at all tO on-line 
mis eric tl On. Furthermore, within an environment, the user 
should be able to set the “help level" on a tool-by-tool 


basis (fine granularity of help levels). 


As an example, suppose a user wanted to use a PL/I 
“while" loop in a program. He could first ask for a tem- 
plate. The system might then want to know which form of the 
“while' loop was desired and display a list of short but 
descriptive names. If this wasn’t enough, the user could 
ask to have the alternative templates themselves displayed 
and if he still couldn’t make up his mind, he could ask for 
detailed instruction on the characteristics and typical uses 
of the different types of "while" loops. Such a system 
would provide for all levels of expertise while penalizing 
no one. (Note the incorporation of the Localized Cost 
principle of CRef. SJ here.) 

The second principle in this category is that of 
using “Names Not Numbers". This is almost identical to the 
Labeling principle of (Ref. SJ. Hansen does, however, pro- 


vide the additional recommendation that a dictionary of 
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names (labels) be maintained by the environment on-line so 
they can be easily referenced to refresh the user’s memory. 

The third principle is that of "Predictable Behav- 
LGte:). Although Hansen provides no precise definition, his 
concerns appear to fall mainly within the realm cof the 
Regularity. Simplicity and Syntactic Consistency principles 
of CRef. adie Certainly, unpredictable behavior cannot be 
tolerated since a user would quickly become frustrated. 

The last principle listed by Hansen in this category 
is that of “Access To System Information." Here, he seems 
to be discussing the need for a user to have at least par- 
tial control over his interface with the environment. This 


need is captured in the following principle: 


Lonfigurability Principle 
The user should be able to configure his interface to the 
environment (tool ) within the constraints mandated by 
higher management. This capability should display a fine 


Qranularity. 


For example, in order to support the organizaticnal 
goals of a software development organization, the various 
levels of management must be able to reserve the alteration 
of environmental features according to organizational poli- 
cies. Those features not reserved to management should be 
accessible to the end user so that he may tailor the 


remainder of the environment to his own liking. One example 
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of such "tailoring" was given earlier in connection with 
setting "help" levels. 
2. Optimize Operations" 

The first of Hansen’s principles in this Category 
sts "Rapid Execution Of Common Operations." Efficient exe- 
cution of frequently used commands is needed to reduce user 
frustration and make effective use of system resources. 
Less frequently used functions or ones that involve so much 
work they cannot be made to appear instantaneous will take 
longer but should, nevertheless, give the user some positive 


feedback while they are in progress. We capture these ideas 


in the following three related principles: 


Meaningful Response Principle 
The appearance of the display and the text of messages in 
response to user actions must be appropriate to those 


actions. 


Rapid Response Principle 
Simple and frequently used functions should Rave an 
immediate (in terms of human reflexes) effect upon the 


display. 


Status Reporting Principle 
Lengthy functions should periodically update the display 
to assure the user that progress is being made in carrying 


Out the requested function. 
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The second principle given by Hansen in this category 


involves "Display Inertia". It mav be stated as follows: 


Display Inertia Principle 
The display should change by the least amount possible in 
response to a user action. The display should not, how- 


ever, violate the Meaningful Response principle. 


The third of his principles involves what Hansen 
calls "Muscle Memory". He notes that repetitive operations 
like typing are relegated to the lower part of the brain and 
therefore different tools should use similar keystrokes to 
perform similar functions. For example, the "escape" key 
should not be used as an "emergency exit" to return one tool 
to some "base state" while another tool in the same environ- 
ment uses the “escape” character as a special kind of de- 
limiter. This) author, like anyone else who has used a 
variety of similar interactive tools (e.g. text editors) on 
a variety of systems, has found the lack of standardization 
of commands and key assignments to be extremely frustrating 
when the same small number of basic functions are being 
performed. 

Another important aspect mentioned by Hansen is 
“burst mode input." He notes that interactive users tend to 
type in short bursts sometimes exceeding 196 words per 
minute. While it is not essential that the system be able 


to respond to commands at this rate, it is essential that it 
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be able to reliably accept both commands and data at what- 
ever rate they are being typed. 

The last principle Hansen mentions in this section 
involves being prepared to "Reorganize Command Parameters". 
His Main concern here is in being able to adjust the user 
interface to reflect the lessons learned through actual 
experience. The most powerful way to do this is to put the 
necessary adjustments in the hands of the user himself. We 
have already mentioned the Configurability principle in this 
regard. Since we can’t possibly expect to anticipate all of 
a user’s needs, we should also seek to make the environment 
extendable within certain constraints. That 1S, we should 
Give the user the opportunity to create and use some of his 
Own "private tools" CRef. 3843 and commands. For example, 
some operating systems have “command files" where commonly 
used command sequences can be placed by a user and invoked 


aS a Single command. We state the following principle: 


Extensib2l ily FP rinG) pie 
An environment should be extensible in the sense that it 
must be possible to add tools at any time and at any level 
which enjoy the same level of control and integration as 


the original tools. 


The combined effects of configurability and extensibility 
effectively remove the need for the detailed user profiles 


mentioned earlier. 


As noted earlier, humans are error prone. Hansen's 
first principle in this section is the provision of "Good 
Error Messages." We consider this as being included in the 
Meaningful Response principle since the correct response to 
an erroneous input is a good error message. 

Hansen*s mext principle is worthy of its own place 
in the sun, however. He states it as, “The System Must 


Provide Reversible Actions." We state it as follows: 


Reversibility Principle 
Any action taken by a user must be reversible for some 


period of time or number of subsequent actions. 


Reversibility is one of the most important ergonomic 
principles. Because humans are so error-prone, they tend to 
take actions which they later need to reverse or “undo." £No 
one would expect a user to be happy if, after spending 39 
Tinutes composing a paragraph, he then struck the “delete 
paragraph" key when he meant to strike the "delete word" key 
and found he could not recover from his error except by 
retyping the entire paragraph. 

The Cornell Program Synthesizer [Ref. 24] 4carries 
reversibility one step further - "reverse execution" of a 
program in support of debugging activities. As described in 
[Ref. 24], "... the forward execution interpreter maintains 


a history file of the flow control and the values destroyed 
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by assignments to variables. The reverse execution inter- 
creter restores values and updates the screen to give the 
illusion of the program executing backwards." 

4. "Perception Aids" 

This category comes from CRef. I06]. There, Spier et 
21) ee describe the "windows" concept which has come into 
recent popularity through the work on Smalltalk (CRef. 335) 
and some recent personal computer products (e.g. Apple Com- 
puter*s Lisa and MacIntosh systems. and Microsoft’s Windows) 
Windows basically provide a mechanism for easy context 
Switching by the user without the irretrievable loss of 
previous contexts. As pointed out in fRef. 3G], "It should 
be trivial to interrupt an activity, embark upon another 
(Which is Similarly interruptable), and later resume the 
gerst activity.” The ability to display multiple windows 
Simultaneously (though some may be partially hidden) gives 
the user interface a fine granularity. 

Spier et al. also advocate the use of high resolu- 
tion color graphics to enhance user perception. Graphics 
have application throughout the software engineering process 
and are often a much more effective communications medium 
than even the most imaginatively formated text. The promi- 
nence of graphical representation in the design documenta-— 
tion systems of the other, older engineering disciplines is 


no accident. 
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C. CONCLUSIONS 

In the preceeding paragraphs we have tried to stress the 
importance of having a well engineered user interface to any 
interactive application. We then listed a number of impor- 
tant principles for the design of user interfaces. The list 
was by no means exhaustive but it did point out a number . of 
often overlooked but important issues. The most important 
conclusion to draw 1s that a tool which 1s difficult or 
awkward to use will not be used if an alternative exists, 
and will be used inefficiently at best even if there is no 


alternative. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 
A. SOFTWARE DEVELOPMENT AS “ENGINEERING" 

When software 1S compared with other complex artifacts 
which are "engineered" rather than "crafted" we find many 
more Similarities than differences. In spite of this, soft- 
ware development is still more of a craft than an = engineer- 
ing discipline. Although this situation may be understand- 
able given software engineering’s youth, it 1S nonetheless 
important to speed its maturation as much as possible. 

The similarities software artifacts share with other 
products of an engineering development process inmclude a 
high degree of complexity, a requirement for a reasonably 
long useful life of continuous, reliable operation, the need 
for alteration, enhancement and, ina sense, “repair” during 
its life, a requirement that it be serviceable by people not 
intimately involved with its original development, and a 
requirement that it be operable by persons who are ignorant 
of its internal structure and operation. While software has 
no moving parts to wear out, neither, in most cases, to 
solid state electronic circuits. However , like an elec- 
tronic circuit, software may be released with flaws that are 
not immediately apparent and, when these manifest 


themselves, "repair" or replacement 1S 1n order. 
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Software is different from other artifacts in that its 
implementation is not a physical object. This 18S really the 
only significant difference and itS main impact is to 
require that a little extra imagination be used to represent 
software designs. 

As implied by the first paragraph, software engineering 
1s quite different from the methods of the more mature 
engineering disciplines. In fact, it 1S questionable at 
this time whether a software engineering discipline can be 
said to exist. The most obvious difference seems to be the 
lack of a complete and universal software design documenta-— 
tion technology. This failing seems to be at once a symptom 
and a cause of a Significant difference in the way engineer-— 
ing project resources are employed. In all the older engi- 
neering disciplines, design and implementation are separate 
activities uSually carried out by separate groups of people 
who communicate mainly via the design documentation (e.g. 
blueprints). In software "engineering" design and imple- 
mentation are still inseparable activities, and it 1s for 
this reason that software development remains a "Craft." 

Design documentation is also needed to communicate from 
the designer to maintenance personnel, operators and tater 
designers a wealth of needed information. Without design 
documentation, the burden of communicating this information 


to all those with a "need to know" would be unmanageable. 
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It 15 a strange paradox that Brooks CRef. 16] decries 
flowcharting as a “Space hogging exercise in drafting" while 
at the same time observing that adding people to a late 
software project only serves to make it later because the 
Communications burden of bringing the new people aS ele) 
speed" exceeds the amount of useful work they can do. This 
1s not to say that flowcharting 1S an adequate means of 
documenting a software design. Rather, it serves to point 
out the reluctance of software developers to expend the 
considerable effort required to develop any reasonable 
amount of design documentation. This reluctance stands in 
Stark contrast to the other engineering disciplines. A 
recent radio commercial announcement for a new model of 
automobile points this out admirably. In the announcement, 
it was claimed that the manufacturer had spent over five 
years and over a billion dollars in design effort on that 
particular model before it went into production. Thus, even 
in such a well established sub-field of engineering as auto- 
motive design, Vast amounts of design effort are expended 
routinely, and much of this 15 spent developing the neces- 
sary design documentation. Software development has no 
analogy in this regard and until it does it cannot truly be 


called "engineering." 
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B. SOFTWARE ENGINEERING ENVIRONMENTS 

We can increase the rate of maturation from software 
development as a craft to software development as an engi- 
neering discipline by designing (with whatever design tools 
we have at hand). developing and implementing software engi- 
neering environments that support an analog of the general 
engineering process as adapted to software development. The 
knowledge gained from this work will suggest many more 
improvements in the way we produce software, while at the 
same time improving software productivity in general by 
making many useful tools available. So far, the reluctance 
of the software industry to engage in this activity seems 
paradoxical. 

While basic research on programming languages in general 
should continue, there is probably no need for i ‘further 
efforts with respect to imperative languages. This is be- 
cause we can effectively control, through the environment, 
most af the language’s characteristics which are apparent to 
the programmer. If increases in productivity and quaiity 
are truly our goals, then, at this point, the most nalve 
efforts at software engineering environment design probably 
hold more promise, in the short term, than the most sophis- 


ticated research on programming language design. 
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fee UTrURE WORK 

Clearly the most critical area for future efforts is in 
the area of software design documentation. Design and its 
associated documentation techniques are crucial to the 
Gperation of all engineering processes. Unfortunately, the 
needed research probably doesn’t hold much glory for the 
academician. Certainly the design documentation systems af 
engineering in general were not the result of such research 
(although some may have been by-products of academic inqui- 
ries), but evolved more or less naturally over a long pericd 
of time. This will eventually occur with software as well. 
The problem is that many do not believe we can afford the 


luxury of such "natural evolution” in the face of what they 
term the "software crisis.” 

In particular, we need to find more ways of employing 
Graphics in software design documentation. Pictures can 
often communicate more information in less space. They also 
tend to be more universally understood than textual or 
spoken languages. Furthermore. graphics display devices and 
& reasonable amount of general purpose software to support 
them has fallen into the realm of affordability. This means 
that much of the "drafting" burden can be automated. in 
fact, there is already a trend in the more established 
engineering disciplines toward "computer aided drafting.” 


Another area requiring further research is software 


management. Software management 1S in an even more immature 
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state than software engineering in general. So far we don’t 
hnow how to estimate the cost, time, or complexity of devel- 
oping a plece of software. Furthermore, we don’t know how 
to measure the result of a project for a meaningful compari- 
son with the original (probably meaningless) estimates and, 
worse than that. we usually don’t even try. At least a well 
designed software engineering environment would allow (for 
the collection of project data which, when analyzed, might 


yield some insight into the management problem. 


D. CONCLUSIONS 

Software engineering is still very immature as an = engi- 
neering discipline. Before significant further maturation 
can take place, work must begin on establishing a design 
documentation system that shares the essential characteris-— 
tics of other engineering design documentation systems. 
Software engineering environments with a well integrated set 
of useful tools for aiding design, implementation, quality 
assurance, maintenance and enhancement, and management of 
software hold much more promise for increased software pro- 
ductivity and quality than the traditional approach which 


has restricted itself to programming language design. 
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(After MacLlLemnan [Ref. S]) 


Boscract2zon: Avoid requiring something to be stated 
more than onces factor cut the recurring pattern. 


futompation: Autcmate mechanical, tedious, Or error- 
prone activities. 


Defense-in-Depth: Have a series of defenses so that if 
an error isn’t caught by one, it will probably be caught 
by another. 


Information Hiding: The language should permit modules 
designed so that (1) the user has all of the information 
needed to use the module correctly, and nothing more; 
(2) the implementor has all of the information needed to 
implement the module correctly, and nothing more. 


Labeling: Avoid arbitrary sequences more than afew 
items longs do not require the user to know the absolute 
position of an item ina list. Instead, associate a 


meaningful label with each item and allow the items to 
occur 1n any order. 


Localized Cost: Users should only pay for what they 
uses avoid distributed costs. 


Man2zfest Interface: All interfaces should be apparent 
(manifest) in the syntax. 


Irthogonality: Independent functions should be control- 
led by independent mechanisms. 


POrvaeblil2ty: Avoid features or facilities that are 
dependent on a particular machine or a small class of 
machines. 


Preservation of Information: The language should allow 
the representation of information that the user might 
know and that the compiler might need. 


lee 
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REgGdl ara. Regular rules, without exceptions, are 
easier to learn, use, describe, and implement. 


Secur2ztys No program that violates the definition cf 
the language, or its own intended structure, should 
escape detection. 


2 2 eek ery A language should be as simple as possible. 
There should be a minimum number of concepts with simple 
rules for their combination. 


Serge Gules The static structure of the program should 
correspond in a simple way with the dynamic structure 
of the corresponding computations. 


Syntactic Consistency: Similar things should look simi- 
lar: different things different. 

Zero-One-Infinitys The only reasonable numbers) are 
zer 


e 
ero, one, and infinity. 
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€After Riefer CRef. 15]) 


meenecrple if: The Precedence Principle. Planning logically 
takes precedence over all other managerial functions. 


Principle 2: The Effective Planning Principle. Plans will 
be effective if they are consistent with the organization’s 
policy and strategy framework. 


Pranaciple $: The Living Document Principle. Plans must be 
maintained as living documents or they quickly lose their 
value. Plans serve as the foundation fcr control. When 


they are not updated, control is severely impeded. 


Principle #3 The Early Assignwent Principle. Make one 
person responsible for software as early in the life of the 
project as possible. Ensure that he or she occupies a high 
enough position within the hierarchy to successfully compete 
for resources (dollars, people. etc.). Make this person 
accountable for the final results. 


meanciple 9: The Interface Principle. The efficiency of an 
Organization iS inversely proportionate to the number of 
interfaces it has to maintain during the performance of a 
eee 


Meinuzple «&: The Parity Principie. A software manager's 
responsibility for action should be no greater than that 
implied by the authority delegated to him. 


Principle 7: The Quality Principle. Using a few experi- 
enced people for critical tasks (such as design) is often 
more effective than using larger, unskilled teams. An 


experienced software engineer is “worth his weight in gold." 


Peinciple. 3: The Personnel Development Principle. An open 
commitment to personnel development often pays dividends. 
Better trained technical and managerial personnel can ef- 
fectively cope with tomorrow’s problems instead of today’s. 
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PrIipet ols) The Dual Ladder Principle. Promotion should 
be possible up either a technical or a managerial career 
path. 


Principle 10: The Motivation Principle. Interesting work 
and the opportunity for growth and advancement will motivate 
people to achieve high productivity. McGregor*s Theory Y 
holds - the individual will rise to the challenge of his 
capabilities. 


PRI DG2 pie a7 The Leadership Principle. Feople will fcllow 
those who represent a means of satisfying their own personal 
goals. Success will come to those who ensure that personal 
goals are compatible with those of the organization. 


Prinai ple (2: The Compunications Principle. Productivirgy 
1s a function of the communications burden. As the burden 
increases, productivity decreases. In other words, the less 
communication required, the higher the productivity. 


Principle 13: The Significance Principle. Controls should 
be implemented to alert managers promptly to significant 
deviations from plans. 


Principle 14: The Measurement Principle. Effective control 
requires that we measure progress against objective, ac- 
curate, and meaningful standards. 


Prigne2 ple Wialo- fhe Exception Wer77e7 pie. The efficient 
manager will concentrate his control efforts on exceptions. 


Principle 16:3 The Technology Risk Principle. Technology 
should be used only when the risk associated with it is 
acceptable. 


PRriVa@ ple. 1773 The Improvement Principle. The manager who 
insists on doing things the way they have always been done 
will fail. New approaches must be used to meet new chal- 
lenges. Your competition will not allow you to remain 
conservative in the extreme. 


Principle 18: The Peter Principle of Software Managenaent. 


Managers rise to their level of incompetence and are then 
transferred to head a software development project. 


9& 
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(After Wasserman (Ref. 1417) 
The methodology should cover the entire software devel- 
opment cycle. 


The methodology should facilitate transitions between 
Phases of the development cycle. 


The methodology must support determination of system 
correctness throughout the development cycle. 


The methodology must support the software development 
organization. 


The methodology must be repeatable for a large class of 
software projects. 


The methodology must be teachable. 
The methodology must be supported by automated tools 
that improve the productivity of both the individual 


developer and the development team. 


The methodology should support the eventual evolution of 
the system. 
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APPENDIX D 


— a ee oe ew eee ee ee ee ee — ee ee ee ee ee ee — —<« 


(After Thayer, Pyster, and Wood (Ref. 27)) 


ae Requirements: Requirement specifications are 
frequently incomplete, ambiguous, inconsistent §$ and/or 
unmeasur able. 


Ze success: Success criteria for a software develop-— 
ment are frequently inappropriate, which result in "poor- 
quality" delivered software: 1.-@., not maintainable, un- 


reliable, difficult to use, relatively undocumented, etc. 


Se Project: Planning for software engineering projects 
is generally poor. 


4. Cost: The ability to estimate accurately the re- 
sources required to accomplish a software development is 
poor. 


wa schedule: The ability to estimate accurately the 
delivery time on a software development is poor. 


o% Design: Decision rules for use in selecting the 
correct software design techniques, equipment, and aids to 
be used in designing software ina software engineering 
project are not available. 


ce Test: Decision rules for use in selecting the 
correct procedures, strategies, and tools to be used in 
testing software developed in a software engineering project 
are not available. 


8. Maintainability: Procedures, techniques, and strat-— 
egies for designing maintainable software are not available. 


9. Warranty: Methods to guarantee or warranty that the 
delivered software will "wor k" for the user are not 
available. 


19. Control: Procedures, methods, and techniques for 
designing a project control system that will enable project 
managers to successfully control their project are not 
readily available. 
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ie Types Decision rules for selecting the proper 
organizational structure; 22 Gis Bee Sct. Matrix. ftUnction. 
are not available. 


a. Baeagumeall! 2 2 Tie taGcectmeabtigty Structure iin 
many software engineering projects 1S poor, leaving scme 
question as to who is responsible tor varicus project 
functions. 


+ 


Sse Projsect Manager: Procedures and techniques for the 
selection of project managers are poor. 


14. Techniques: Decision rules for use in selecting 
the correct management techniques for software engineering 
project management are not available. 


1S. Yros2z2bility: Procedures, techniques, strategies, 
and aids that will provide visibility of progress (not just 
resources used) to the project manager are not available. 


VGre Reliability: Measurements or indexes of reliabil- 
lity that can be used as an element of software design are 
not available and there is no way to predict software fail- 
ures i.e... there 1s no practical way to show the delivered 
software meets a given reliability criteria. 


As Maintainability: Measurements or indexes of main-—- 
tainability that can be used as an element of software 
design are not available: i.e., there is no practical way to 
show that a given program is more maintainable than another. 


18. Goodness: Measurements or indexes of "goodness" of 
code that can be uses as an element of software design are 
not available; i.e., there is no practical way to show that 
one program is better than another. 


ive Programrpers: Standards and techniques for measur- 
ing the quality of performance and the quantity of produc-— 
tion expected from programmers and data processing analysts 
are not available. 


Sed 


AL) Tracing: Techniques and aids that provide = an 


acceptable means of tracing a software development from 
requirements to completed code are not generally available. 
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MHethodology Support: A software engineering environment 
Should be designed to support a specific engineering 
methodology. 


Design Documentation: A software engineering environ-— 
ment should support a design documentation system that 
1s (1) complete, (2) capable of representing appropriate 
levels and types of abstractions with fine granularity, 
(3) universal, and (4) economical. 


Enforcement/Aid: A software engineering environment 
should enforce technical correctness and conformance 
with management policies while aiding the user iin 
maintaining these standards. 


Consistency Principle: “Permanent” alteration of one 
view of a design should not be "accepted" by the envi- 
ronment until all related views are made to be 


consistent with the change. 


Structure Manipulation: The user of a software engi- 
neering environment should be able to create, reference, 
locate, alter, and delete structures defined within the 
environment. He should also be able to display meaning- 
ful representations of them within the context of any 
applicable type or level of abstraction. 


Static Analysis: A software engineering environment 
should (1) allow the user to make assertions about the 
Static structure of a module, program, or system =<af 
programs and then report back to the user which asser- 
tions are not valid and why, and (2) allow the user to 
request certain information about the static structure 
and then report this information back to the user in a 
lucid format. 


Dynemic Analysis: A software engineering environment 
should (1) allow the user to make assertions about the 
dynamic structure of a module, program, or system of 
programs and then report back to the user which asser-— 
tions are not valid and why, and (2) allow the user to 
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Pair 
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request certain information about the dynamic structure 
and then report this information back to the user in a 
lUucio tormat- 


Data Collection: A software engineering Environment 
should provide for the unobtrusive collection of soft- 
ware management data. 


Audzt Trail: A software engineering environment should 
maintain audit trails showing the relationships between 
specifications, designs, implementations, maintenance 
and enhancements, and the resources expended in these 
activities. Further, such audit trails should be 
navigable in both directions from any point. 


Information Organization: The information gleaned fram 
the various documentation and data collection efforts 
should be organized for easy reference and maintenance. 


Management Control: A software engineering environment 
must be controllable by the management of the organiza-— 
tion it serves. 


Organizational Structure: A software engineering envi- 
ronment should be partitionable along the structural 
lines of the organization so that individuals and groups 
may have the necessary levels of privacy and isolation 
From other individuals and groups, and so the communica-— 
tions among them may be reasonably controlled by forcing 
them through established interfaces. However, it should 
also be possible to allow information to flow across 
Organizational boundaries, when needed, through special-— 
ly designated and controlled interfaces. 


Interface Language Design: The language of interaction 
between a user and an interactive application should se 
designed according to the principles of good programming 
language design. 


Multi-level Help: For any interactive tool, there 
should be a hierarchy of "help" levels ranging from Ao 
prompts at all to on-line instruction. Furthermore, 
within an environment, the user should be able to set 
the "help level" on a tool-by-tool basis (fine granu- 
larity of help levels). 


Configurabilicy: The user should be able to configure 
his interface to the environment (tool) within the con- 
straints mandated by higher management. This capability 
Should display a fine granularity. 
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Meaningful Response: The appearance of the display and 
the text of messages in response to user actions must be 
appropriate to those actions. 


Rapid Response: Simple and frequently used functions 
should have an immediate (in terms of human reflexes) 
effect upon the display. 


Status Reporting: Lengthy functions should periodically 
update the display to assure the user that progress is 
being made in carrying out the requested function. 


Qrisplay Inertia: The display should change by the least 
amount possible in response to a user action. The 
display snould not, however , Violate the Meaningful 
Response principle. 


MY Censi@i22 cy: An environment should be extensible in 
the sense that 1s must be possible to add tools at anv 
time and at any level which enjoy the same 1level of 
control and integration as the original tools. 


Reversibility: Any action taken by a user must be 


reversible for some period of time or number cf 
subsequent actions. 
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